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Abstract 

We present a comprehensive formal semantics for a UML state machine kernel which also consid¬ 
ers the use and manipulation of complex structured data. We refer to the UML standard Version 2.1.1 
which was published in year 2007. There has been no work that completely integrates complex struc¬ 
tured data into a UML state machine semantics. We follow a ’’semantics-first” approach (in opposite 
to a ’’complete-notation-first” approach) in which we consider a sound basic kernel of the UML state 
machine notation, and extend this kernel only ater a thorough investigation of the impacts. We define 
an operational semantics which is intended to be implemented in a standard programming language. 
Currently we use such an implementation to automatically generate test cases out of a state machine 
specification. This document is intended to be adapted if necessary. We will indicate that by the version 
number given above, whereat the major version number indicates changes of the considered subset and 
the minor version number indicates adoptions and corrections. 


The considered UML state machine subset includes: 

1. Hierarchically and orthogonally structured states. 

2. Multi-level transitions. 

3. Use and manipulation of an associated data space. 

4. Events comprising complex structured data. 

5. Complex guards to control the firing of transitions. 

6. Complex actions to update the data space and to generate new events. 
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1 Introduction 


The Unified Modeling Language (UML) comprises thirteen diagram types to specify structure and behavior 
of a system or a system component [22], The included state machines are used to either describe the 
discrete reactive behavior of a system (behavioral state machines) or to describe the usage protocol of a 
system (protocol state machines). We focus on behavioral state machines and use them to specify the states 
a system can take and actions it can execute during its lifetime in response to internal and external events. 
The discrete reactive character of state machines and the possibility to completely specify the behavior of 
a system make state machines appropriate to model reactive systems. 

State machines are an object-oriented extension of the classical Harel Statecharts [4]. They are mathemat¬ 
ical models with a graphical representation: the nodes depict simple or composed states of the system and 
the labeled edges depict transitions between these states. Composite states are used to hierarchically and 
orthogonally structure the model, thus reducing its graphical complexity. Simple composite states contain 
exactly one region and orthogonal states contain at least two regions. In every region only one state must be 
active at a time. The state which is entered by default if the enclosing region is entered, is marked by a tran¬ 
sition emanating from a filled circle (called the default transition). Labels express conditions under which 
transitions can be taken and the actions that will be executed when the transitions are taken. Events are used 
as triggers to activate transitions and can be parameterized to exchange data. Optional, every state machine 
has a data space that can be read and manipulated by the state machine during its execution. More pre¬ 
cisely, it is possible to read data values to describe fine-grained conditions when a transition can be taken, 
or to manipulate data values and exchange information within the actions. A transition comprises a source 
state, a trigger event, an optional guard, an optional effect (which consists of a sequence of actions), and 
a target state. A guard describes with a possible reference to the state machines data space a fine-grained 
condition that must evaluate to true to enable the transition. Hence, the activation of the source state, the 
available trigger event and the fulfilled guard condition constitute the precondition of the transition. An 
action can either be a statement manipulating the data space or the generation of new events. Hence, the 
action sequence and the subsequently reached target state constitute the postcondition of the transition. In 
opposite to the classical Statecharts, the event processing takes place in a so-called run-to-completion step. 
This asynchronous event processing demands the processing of the previous step to be completely finished 
before the next step can be executed. In the following we introduce the state machine notation by means 
of an simple example, namely a Car Audio System. The principle user interface of this system is shown in 
Figure 1. The textual requirements for the Car Audio System could be as follows: 

It should be possible to turn the Car Audio System on and off. When turned on, it should 
play one of three different audio sources, namely radio, tape or compact disc, respecting the 
presence of a tape or a compact disc. It should be possible to change between available sources. 
Furthermore, it should be possible to switch between four radio stations, to spool a tape back¬ 
ward or forward, and to select the previous or the next track of a compact disc. 


ON 

OFF 


SRC 


[> 


CD - DRAWER 


DISPLAY 


TAPE - DRAWER 


CDEJECT 


Figure 1: User interface of the Car Audio Sysem. 

Based on the textual requirements we introduce the following events to model the required behavior: 
power, src (to switch between the different sources), next, back and play. We also introduce events 
signaling the insertion and the ejection of a tape or a compact disc as well as events to signal system reac¬ 
tions (ccLinsert, ccLe ject, tape.insert and tape_e ject). Furthermore, we use data variables 
to store detailed information about the current state. We use an integer variable trackCount to store the 


4 










































number of titles of an inserted compact disc, and the two boolean variables inCDFull and inTapeFull 
to store if a compact disc and a tape are inserted into the Car Audio System. We will use this variables to 
control the switching between the different sources. In most applications a state machine is assigned to a 
class diagram describing the behavior of the class instances. In this setting, the class attributes constitute 
the data space of the state machine. The events of a state machine will also be represented as classes having 
their own attributes. We differentiate between events which are referenced by the state machine (i.e., to 
send events to other system components) and events which will be processed by the state machine. Figure 2 
shows the class diagram for the Car Audio System and the related state machine model. 



Car Audio System 


Car Audio SystemJ 

int trackCount = 0; 
boolean inCDFull = false; 
boolean inTapeFull = false; 





Figure 2: Class diagram for the Car Audio System. 

Figure 3 shows a state machine model of the Car Audio System and the related data space. At the highest 
level of abstraction the state machine CarAudioSystem consists of an orthogonal state which comprises 
three regions. The two regions CD Player and Tape Player model if a tape or a compact disc are 
present in the system. The more complex region Audio Player models the control unit of the Car 
Audio System. It is refined by two states, namely Off and On. By default the system is assumed to 
be switched off. If an event occurrence power is processed the system is switched on and starts to play 
the radio (due to the default transition). The composite state On is refined into states modeling the three 
signal sources. The transitions between these states describe the changes between the sources as reaction 
to an event occurrence src. For example, if the system is in Tuner Mode and a tape and a compact disc 
are inserted into the system (i.e., the boolean variables inCDFull and inTapeFull are true) and an 
event occurrence src is processed, the system can either switch to the tape mode or switch to the compact 
disc mode since both transitions are enabled. All three substates of Audio Player are further refined 
to describe the particular behavior in reaction to the events next, back and play in each state. If a 
transition is taken (the transition is said to fire) the associated action sequence is executed. That includes the 
generation of new event occurrences and the manipulation of the data space. For example, if the transition 
from state CD Empty to state CD Full in region CD Player fires, the attribute assignments changes such 
that inCDFull is set to true and that trackCount is set to the value of the first parameter of the 
triggering event occurrence cd_insert. 

Semantic Variation Point 1 (Expression Language) 

The UML standard indicate that the expression language which can be used to specify guards and actions 
depends on the chosen action language for the state machine (usually the target programming language). 

□ 

This allows a wide application domain for state machines. But it considerably complicates formal reasoning 
about state machine models. Currently, we use a subset of the Java programming language [10] to specify 
guard and action expressions. For the future we propose to define an independent expression language 
which can be mapped to an action language but which allows formal reasoning. 

The hierarchical alignment of state machine states forms a tree structure with a region as the root node. 
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boolean inCDFull = false; boolean inTapeFull = false; integer trackCount; 




Figure 3; State machine model of the Car Audio System and the associated tree structure. 
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simple states at the leaves and alternating composite states and regions in between. Figure 3 shows this 
structure for the state machine Car Audio System. Regions are depicted as dotted nodes and have an 
optional name. State are depicted as simple framed nodes, whereat default states are depicted as double 
framed nodes. The transitions are depicted as dashed arrows. In the tree structure it is easily identifiable 
which state will be left and which state will be entered if a transition is taken. Affected by the transition 
is the subtree which contains both the source state and the target state. Most transitions are within one 
hierarchy level. But it is also possible that a transition crosses multiple hierarchy levels. Such transitions 
are called multi level transitions. For example, the transition leaving state Tape Mode and entering state 
Of f is a multi level transition. The transition could model, for example, that if the tape reaches its end the 
Car Audio System is turned off. The affected subtree can be also easily identified. 

We use for all definitions as the basic notation the Z Formal Specification Notation. An introduction to 
Z and its formal semantics can be found in [20, 23, 9, 17], With respect to a tuple p == (ci,... ,c„), we 
denote with p.l=c\, ... , p.n = c„ the corresponding component of p. 


2 Abstract Syntax 

2.1 States and Regions 

A state machine is composed of hierarchically and orthogonal structured states. The nodes set comprises 
the states as well as the regions of a state machine. Regions are used to group refining states. States, which 
are not further refined, are called simple states. States, which are further refined, are called composite states. 
Composite states which are refined by exactly one regions are called simple composite states. Composite 
states which are refined by at least two regions are called orthogonal states. 

Definition 1 (Node Set) 

Let N denote the given non-empty, finite set of states and regions. 

□ 

We distinguish among the states in N four types, namely region, simple, simple composite and orthogonal. 

Definition 2 (Type Function) 

Let N be the set of nodes. The function type takes a node as input and yields the type of the node. 
type : N —> {region, simple, simple composite, orthogonal} 

□ 


Remark: Regions and states of a state machine are represented in the UML standard as separate classes. 
Hence, they are distinguished by their type. The different state types are distinguished based on three class 
attributes. The boolean attribute issimple indicates if the state is a simple state. The boolean attribute 
isComposite indicates if the state is further refined. Finally, the boolean attribute isOrthogonal indicates if 
the state is an orthogonal state. Using a type function avoids unnecessary redundancy since invalid attribute 
combinations are avoided. The relation between these class attributes and the function type is as follows. 

Definition 3 (Attribute Mapping) 

The following relation exists between the used node types and the UML class attributes. 

simple isSimple 

simple composite •<=> -i isSimple A isComposite A -i isOrthogonal 
orthogonal ■£=> -i isSimple A isComposite A isOrthogonal 

□ 
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Remark: Simple composite states are also called vor-states and orthogonal states are also called and- 
states. This is motivated by the number of simultaneously active direct substates. Refined states contain 
regions. Within a region exactly one state must be active at a time. Simple composite states contain exactly 
one region in which exactly one state is active (i.e., there is a exclusive choice among the states: xor ). 
Orthogonal states contain at least two regions. Consequently there are at least two states simultaneously 
active at a time (i.e., exactly one state in every region: and). 

The node hierarchy of a state machine is given by a tree ( N,H ), where N denotes the node set and H : 
P(/V x N) denotes the non-empty subnode relation. A tuple n i—> n': H indicates, that node n is refined by 
node n! (i.e., n! is a subnode of n). Based on the subnode relation we define relative to a node three different 
nodes sets. 

Definition 4 (Subnodes Sets) 

Let (A, H ) be the node hierarchy, and let H denote the transitive closure of H. The functions subnodes : 
N—>¥N takes a node n : N as input and yields a set of direct subnodes of n. The functions subnodes* and 
subnodes* yield the transitive and transitive-reflexive closures, respectively. 

subnodes(n) == {n : N | n i—> n! £ H} 
subnodes + (n) == {n : N \ n*—> n' £ H + } 
subnodes*{n) == {n}U subnodes + {n) 

□ 

Is «2 £ subnodes*{n\ ) we say that n\ is a supernode of ni, and that nj is a subnode of n\. Due to the 
reflexivity of subnodes* n is supernode as well as subnode of oneself. Is «2 £ subnodes + {n\) we say that 
n\ is a strict supernode of « 2 , and that 112 is a strict subnode of n\. 

It is required that a region is refined by at least one state, a simple composite state is refined by exactly 
one region, and an orthogonal state is refined by at least two regions. This implies that regions and state 


alternate in the tree structure and that the leaves are simple states. 

Definition 5 (Well-formed Node Hierarchy) 

A well-formed node hierarchy (N,H) must preserve the following constraints. 

3j n : N • n ran// A nedomfl A bn' :N\{n} •3 l n" :N • n" 1 —> n' £H (1) 

bn : N | type (n) = region • {'bn : subnodes{n) • type ( n’) ^ region ) (2) 

bn: N | type (n) = simple • subnodes(n ) = 0 (3) 

bn : N | type ( n ) = simple composite • {bn 1 : subnodes{n) • type (n / ) = region) A {#subnodes{n) = 1) (4) 

bn : N | type ( n ) = orthogonal • {bn 1 : subnodes{n) • type (?/) = region) A ( #subnodes{n ) >1) (5) 

□ 


Constraint (1) requires in a well-formed node hierarchy a tree structure. That means, that there exists a 
distinguishable root node, all remaining nodes have exactly one supernode, and that there exists no loops 
in the structure. From the UML standard it follows that the root node must be a region (cf. Definition 6). 
Constraint (2) to (5) characterize the different refinement variants for states and regions. They include, that 
the leaves of the tree structure are simple states (V n : N \ $n r : N • n 1 —► n 1 : H • type (n) = simple). 

Definition 6 (Root Region) 

Let {N, H) be the node hierarchy, root denotes the root region of the inherent tree structure in H. 

root == pn : N \n £ ran H 
type {root) = region 

□ 

The substate relation H is injective and, except for the root region, surjective. The inverse relation // 1 is 
a partial function which yields the container of a node. 
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Definition 7 (Container Function) 

Let (. N,H) be the node hierarchy. The partial function container : N N takes a node n : N \ {root} as 
input and yields the direct supernode n' : N of n. We call n' container of n. 

container (n) == fl n' : N \ n! i—> n G H 

□ 

We call the state which will be activated if one of its supernodes is activated default state. This is in 
opposite to the common literature. There, such states are called initial states. We use a different term since 
not all default states are initially active (e.g., if an enclosing orthogonal state is not initially active). 

Definition 8 (Default States) 

Let ( N,H) be the node hierarchy. The set N C N comprises all default states. 

Vn : N | type (n) = region • 3 x d : N | d € subnodes(n) • d £ N 

□ 


2.2 Events 

Events are used to trigger transitions. They can be parameterized to exchange detailed information. An 
event comprises of a name and a finite number of data partitions. In practice, the event name corresponds 
to the class name and the particular data partitions correspond to the attributes of this class. 

Definition 9 (Event Names) 


Let S denote the given set of event names. 

□ 


Definition 10 (Event Instances) 

Let K be an index set with n elements, and let (PfjtK a family of sets P,. The set E v denotes the set of all 
event instances to an event name v : S. 


Ey ==v((P 1 X ... XP„)) 

a 

Definition 11 (Event Set) 

Let S be the set of event names. The set E denotes the set of all event instances with respect to S. 

E== | Ey 


The set E is the disjunctive union of all particular set of event instances. We call a member of the event 
set event instance and denote it v(. ..). To demonstrate the construction of an event set we give a small 
example. 

Example 1 (Set of Event Instances) 

Let S\ = {a,b} be a set of event names, and let a have two parameters of type N and bool, and let b have 
one parameter of type B. The set E\ denotes the set of all event instances with respect to S. 

Parameter sets: P c { = N A P$ = B 

p\ = B 

Sets of event instances: E a = a((N,B)) = {a(0,true), a(0,false), a(l,frne), a(l,false), ...} 

Eb = ft((B)) = {b(true), bffalse)} 

Set of all event instances: E\= E a \ Eb = £« W Eb = {a(0, true), a(0,false), ... , b(true), blfalse)} 
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□ 


The transitions of a state machin SM can only be triggered by a subset of the event instances in E. In 
anticipation of the following dehnitions we distinguish four subsets of E. First, a subset which comprises 
all event instances which can trigger transitions of the state machine: E$m Q E. Second, a subset which 
comprises all event instances which are sent by the state machine to other system components: Eenv C E. 
We further distinguish two subsets in E$m- Third, a subset which comprises all event instances which can 
only by used by the state machine itself: E p ^ C E$m- Forth, a subset which comprises all event instances 
which can also be used by the environment E p ^ C E$m- This set represents the public interface of the 
state machine SM. With respect to these subsets the following constraints apply: E p ^ tfcl E pu ^ = E$m and 
Esm^Eenv = E. Figure 4 illustrates the partition into the different subsets. 



Figure 4: Partitioning of the set of event instances E. 


2.3 Data Space 

A data space is associated to every state machine comprising a finite number of data partitions. These 
partitions can be read and manipulated during the execution of a state machines. In practice, the class 
attributes correspond to the data partitions of an associated state machine. 

Definition 12 (Data Space) 

Let K be an index set with n elements, and let (P,)i-K a family of sets P,. The set D denotes the set of all 
data space assignments. 


D == P\ x ...x P n 


□ 


2.4 Guards 

A guard is a condition that provides a fine-grained control over the enabling of a transition. It is a function 
which with takes an event instance and a data space assignment as inputs and yields a boolean value 
indicating, if the specified condition is fulfilled. The expression language for guards is defined by the used 
action language (cf. Semantic Variation Point 1). From the UML standard it is only required that guards 
should be pure expressions without any side effects. Guards with side effects are ill formed. Please note 
that the event instance is not part of Definition 13 and 14. It will be added in Definition 15. 

Definition 13 (Guards) 

Let D be the data space. The set G denotes the set of all guard functions. 

G==D-> B 

□ 
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2.5 Actions 


The effect of a transition is a sequence of actions which will be executed if the transition fires. An action 
can either be a statement updating the data space or the generation of a new event instance. Updating the 
data space means that a new data space assignment will be selected. Generating a new event instance means 
that an event instance will be selected. In practice, the effect correspond to the execution of the action code 
and the generation of new event class instances. 

Definition 14 (Actions) 

Let D be the data space, and let E be the set of all event instances. The set A denotes the set of all action 
functions. 

A == event((D -+> E)) | update((D -+> D)) (6) 

□ 


2.6 Transitions 

Transitions describe the state changes in state machines. Graphically, they are directed labeled edges 
between the source state and the target state. A label comprises a trigger, an optional guard and an optional 

£ [g] / A 

sequence of actions. We denote with n\ -> nj a transition graphically, where n \ denotes the source 

state, e denotes the triggering event instance, g denotes the guard, A denotes a sequence of actions, and n 2 
denotes the target state of the transition. 

Definition 15 (Transitions) 

Let (N,H) be the node hierarchy, let $ be the set of event names, let E be the set of all event instances, 
let G be the set of all guards, and let A be the set of all actions. The set T : P (N x (E-^Gx seqA) x N) 
denotes the set of all transitions. A well-formed transition set must preserves the following constraints. 

V/: T • 3j v : $ • E v C E$m A domf.2 = E v (7) 

Vt\T\ e .E\ d : D • e £ domf.2 A 

t.2(e).1(d) =>Vi: dom t.2(e).2 • (let a == t.2(e).2(i) • (8) 

(V/ : D~^E \ a = event(f) • d £ dom/) A (V/ :D-»D \ a = update(f) • d £ dom/)) 

□ 

Constraint 7 requires that a label function must be defined for all event instances to an event name, whereat 
the set of possible event instances is restricted to that of the state machine. Constraint 8 requires that if 
the label function is applied to an event instance and the guard function applied to a data space assignment 
evaluates to true, all action functions must be defined as well. 


2.7 State Machine 

Definition 16 (State Machine) 

Let (N,H) be the node hierarchy, let N be the set of default states, let E be the set of event instances, let D 
be the data space, let G be the set of guards, let A be a set of actions, and let T be a set of transitions. The 
tuple SM denotes a state machine. 


SM== ((N,H),N,E,D,G,A,T) 


(9) 

□ 


A state machine is well-formed if Definition 5 and Definition 15 apply. 
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3 Semantics 


The semantics of state machines is defined by means of executing a hypothetical machine (i.e., to processes 
events and to executes transitions). This comprises the execution of semantic steps which describe the 
transition from one semantic state to the subsequent semantic state. 


3.1 Active State Configuration 

A state machine can be in more than one state at a time due to its hierarchical and orthogonal structure. We 
call a set of simultaneously active states an active state configuration or just configuration. 

Definition 17 (Active State Configuration) 

Let SM = be a state machine, and let root be the root region of SM. The set 

C : PPA denotes the set of all active state configurations of SM. 

C == {c : PA | (Vs : c • type (s) region A 

3j s': subnodes(root) • s' £ c) A 

(Vs : c | type(s) ^ simple • Vr : subnodes(s) •3 1 s" : subnodes(r) • s" € c / )} 

□ 

An active state configuration comprises no regions. It is required that exactly one direct substate of the root 
region is contained in an active state configuration. For all states in an active state configuration which are 
composite states it is required that for every region refining this state, exactly one direct substate is also 
contained in the active state configuration. An active state configuration can be visualized as a complete 
subtree of the state machine’s tree structure. We call an active state configuration c start configuration if it 
comprises only default states c C N. 


3.2 Event Store 

Information exchange is realized by sending and receiving of events to and from the environment of a state 
machine. Events for internal communication and events which will be received from the environment will 
be buffered until they are processed. 

Semantic Variation Point 2 (Event Store) 

Events will be buffered in a state machine until they are processed. The nature of this event store is not 
specified by the UML standard. 

□ 

It is left open to the user of state machines to specify the behavior of the event store. To respect this variation 
point we define the inductive data type event store. An event store is either empty or it is composed of an 
event instance and an event store. 

Definition 18 (Event Store) 

Let E be the set of event instances. Q denotes the data type of an event store. 

Q == () | add{{Q x E)) (10) 

□ 

We use the function ®:gx seq E —> Q to add a sequence of event instances to an event store and we use 
the partial function Q : Q-» Q x E to remove an event instance from a non-empty event store. With it we 
abstract from a special order of event instances in an event store. In most practical applications, the type Q 
is instantiated by a FIFO-queue. 
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3.3 Semantic State — Status 


A semantic state of a state machine, called a status, comprises an active state configuration, an event store 
and a data space assignment. 

Definition 19 (Status) 

Let SM = (( N,H),N,E,D , G,A, T) be a state machine, let C be the set of configurations, and let Q be the 
set of event stores. The set Z denotes the set of all status of SM. 

Z == CxQxD (11) 

□ 


We denote with [{c,q.d}} a member of Z. An initial status comprises the start configuration. 


3.4 Transition Selection 


During a semantic step the state machine moves from one status to the subsequent status. If an event 
instance is selected for processing one or more transitions can be activated for firing. If no transition is 
activated, the event instance will be discarded. Please note, currently we do not use the notion of deferring 
events. 

Semantic Variation Point 3 (Discarding Events) 

Although the UML standard defines that an event instance which does not enable a transition and which is 
not in the deferred event list will be discarded, we note that in practice this behavior could be unwanted. 
For this reason we mark the discarding of event instances as a semantic variation point. 

□ 

A transition is called enabled, if the source state of the transition is included in the current configuration, 
the event name is equal to the trigger name and the guard evaluates to true. 

Definition 20 (Enabled Transition) 

Let SM = (( N,H),N,E,D, G,A,T) be a state machine, let [[c,#,£/]] : Z be a status, and let (q',e) == Qq be 
the result from removing an event instance e from the event store q. The function enabled : T x C x E x 
D —> B takes a transition t : T, a configuration c, an event instance e, and a data space assignment d : D as 
input and yields a boolean value indicating if the transition is enabled. 

,, ( true if (f.l e c) A (e € domf.l) A (t.2(e).\(d)) 

enabled (t,c,e,d) == < (12) 

\false otherwise 

□ 

Transition are allowed to cross multiple level in the node hierarchy. We call such transitions multi-level 
transitions. To correctly deal with multi-level transitions we need to know the scope of a transition. The 
scope allows to identify the set of states which will exited and entered if a transition is fired. This infor¬ 
mation is needed to identify conflicting transitions among the set of enabled transitions. The scope of a 
transition is identified by the least common ancestor of the source and target state. It is of type region or 
orthogonal. 


Definition 21 (Transition Scope) 

Let SM = (( N,H),N,E,D , G,A, T) be a state machine. The function lea : T —takes a transition t: T as 
input and yields the least common ancestor of the source and target state. 

lca(t) == fl n : N \ (f.l £ subnodes + {n)) A 
(t. 3 € subnodes + (n )) A 

(13) 

( $n’ : N | n! g subnodes + (n) • 

f.l £ subnodes + (n') A t. 3 £ subnodes + (n')) 
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□ 


Based on the scope we can identify the main source and the main target of a transition. These two states 
represent the root nodes of the subtrees which are affected by a transition. 


Definition 22 (Main Source and Main Target) 

Let SM = (( N,H),N,E,D , G,A, T) be a state machine. The function mainSource : T —>(V and the function 
mainTarget: T —> N take a transition t: T as input and yield the main source and the main target of t, 
respectively. 


mainSource (t) == 


p s : subnodes{lca (f)) | t.\ £ subnodes*(s) 
lea ( t ) 


if type (lea (t)) 
if type (lea (t)) 


region 

orthogonal 


(14) 


mainTarget (t) 


Ll s : subnodes(lca (t)) \ t .3 £ subnodes*(s) 
lea (t) 


if type (lea (t)) 
if type (lea (t)) 


region 

orthogonal 


(15) 

□ 


The set of states which will be exited if a transition fires contains all substates of the main source that are 
included in a configuration. 


Definition 23 (Exit Set) 

Let SM = ((N, II). N. E. I). G.A. T ) be a state machine, and let Z be the set of status. The function exits : 
T —>PiV takes a transition t: T and a status [c, <?,£/]] : Z as input and yields the set of states which will be 
exited by transition t. 


exits (t,\c,q,d\) == subnodes*(mainSource(t))nc (16) 

□ 

The set of states which will be entered if a transition fires contains all substates of the main target which 
contain the target state or which are implicitly entered by the transition (default states). 

Definition 24 (Enter Set) 

Let SM = ((N,H),N,E,D,G,A, T) be a state machine. The recursive function enters : N x N-+PN takes 
two nodes n \, 112 '■ N as input and yields with respect to n 1 the set of states which will be entered if M 2 is 
entered. 


enters (n\, M 2 ) == 

{hi} if type (n\) = simple 

( {hi}U [J enters (n 1 .m) if type (hi) = simple composite V orthogonal 

n' £subnodes(n\) 

,enters (n" , n 2 ) if type (n\ ) = region 

Where n" = jin'" : subnodes(n\) \ (112 € subnodes*(n'")) V (n'" € N A H 2 ^ subnodes + (n\)). 


(17) 


□ 


If parameter n\ is of type simple, just this state will be entered. Is parameter n\ is of type simple composite 
or orthogonal, this state and its contained regions will be entered (subnodes(n\)). If parameter Hi is of type 
region, we differentiate two alternatives. Either, the direct substate n'" will be entered which contains the 
target state —target £ subnodes*(n"') or the direct substate n'" will be entered which is the default state. 
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The former is the case, if we are moving down the node hierarchy to the target state. The latter is the case, 
if we already passed the target state and are moving down to the leaves of the state hierarchy (i.e., the target 
state is not a substate of n\) — n'" £ N A target subnodes + (n\). This situation arises, if the target state 
is a refined state or we have to enter an orthogonal regions which is not directly entered by the transition. 

The function enters initially applied to the main target (initial parameter n \) and target of a transition 
(parameter ni) yields all states which will be entered by the transition. We use the abbreviation enters (f) 
instead of enters (mainTarget (f), 3). 

It is possible that more than one transition is enabled by an event instance. If more than one transition 
is enabled it may be the case that one or more transitions are in conflict with each other. Such a conflict 
appears, if two transitions exit same states. Firing both transitions would lead to an ill-formed status. A set 
of non-conflicting transitions must be selected for firing. 

Definition 25 (Conflict Relation) 

Let SM = ((N. II).N.E.D. G.A. T ) be a state machine. The relation j): TxT relates two transitions ti,ti : T 
if they are in conflict with each other. 

))== {(t\,ti) - TxT | exits {t\)C\ exits {t 2 ) 7 ^ 0 } (18) 

□ 

We call two transitions t\.t 2 - T conflict-free, denoted t\ \\t 2 , if they are not in conflict (|| == -in'). 

Conflict resolution is carried out in two steps. In the first step, transitions with the highest priority are 
selected. The used priority scheme is defined on the relative positions of the source states in the node 
hierarchy. A transition, whose source state is a strict substate of the source state of another transition has 
priory over this transition. 

Definition 26 (Priority Relation) 

Let SM = ((N. H).N. E. I). G.A. T) be a state machine. The relations -< : T x T relates two transitions 
t\ J 2 ■ T if 1 1 has priority over t 2 , denoted t\ ~<t 2 - 

== {(ti,t 2 ) : T X T | ti.l £ subnodes (t 2 - 1)} (19) 

□ 

If there are still conflicts among selected transitions, we identify sets of transitions in a second step, which 
are maximal with respect to their cardinality and in which all transitions are pairwise conflict-free. Alto¬ 
gether, a so-called transition selection algorithm selects conflict-free subsets of enabled transitions using 
the given priority scheme. 

Definition 27 (Firing Transition Set) 

Let SM = ((A ,H),N be a state machine, let Z be the set of status, let Q be the set event stores, 

let q : Q be an events store and e : E be an events instance such that (q 1 , e) =Q(q), and let [[c, q.d}} : Z be a 
status of SM. A firing transition set 7’ C T must fulfill the following constraints. 

Vf: 7|| • enabled(t,c,e,d) (20) 

Vfi,f 2 : | h 7 ^ h • t\ || t2 (21) 

$t 1 : T\ T|j | enabled(t',c,e : d) • Vf: T\\ • 1 1| tl V t' -< t (22) 

□ 

Constraint 20 requires all transitions in a firing transition set to be enabled. Constraint 21 requires all 

transitions in a firing transition set to be pairwise conflict-free. Constraint 22 requires that there exists no 

transition outside the set which is enabled and conflict free with respect to all transitions in the set, or which 
is enabled and has priority over a transition in the set. 

Semantic Variation Point 4 (Firing Transition Set Selection) 

It is possible that there exists more than one valid firing transition set at a time. The UML standard does 
not specify which set to choose for the next semantic step. 
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□ 

the execution or firing of a transition is defined in three steps. First, the source state and all effected states 
will be exited. Second, the actions of the transition will be executed. Third, the target state and all effected 
states will be entered. If the chosen firing transition set contains more than one transition the order in which 
the transition are executed is not fixed. 

Semantic Variation Point 5 (Firing Transition Set Execution Order) 

The UML standard does not specify an order in which transitions in a firing transition set will be executed. 

□ 

3.5 Semantic Step 

A semantic step describes the transition from one status to the subsequent status. We distinguish two cases. 
The first case covers the situation in which the event store does not contain an event instance. And the 
second case covers the situation in which an event instance can be removed from the event store. In the 
first case, the configuration and the data space assignment remain unchanged. Only event instances received 
from the environment are added to the event store. In the second case, a firing transition set is identified 
and the contained transitions are executed. This may comprise updating the data space and generating new 
event instances. Generated event instances which belong to the state machine are added to the event store. 
Finally, event instances received from the environment are added to the event store. 

A semantic step is atomic and the next semantic step can only be executed, if the current semantic step is 
completely finished — a so-called run-to-completion semantics. We denote with [c, < 7 , d ]] Ew ’?° u, > [[c', q',d' ]] 
a semantic step (^c.q.d]], Ein,E out , [[c'V, d’Y) : Z x seq E p s u * x seq E E nv x Z. 

Definition 28 (Semantical Step) 

Let SM = (( N,H),N,E,D , G,A,T) be a state machine, let Z be the set of status, let [[c,^,t/]] : Z be a status, 
let T 11 CT be a valid firing transitions set, and let E m : seq E p s ^ a sequence of received event instances. A 
semantic step [[c,< 7 ,r/]] E . m,Eout > : Z x seq E P S '^ x seqEENV x Z is defined as follows. 

q G ran add 

W,e) = Q{q) 

c' = (c\ Uvr: 7 || exits (0) U Uvf: 7 || enters M 
A seq G perm({t: •t.2(e).2}) 

(d' ,E gen ) = performAlK^ / A seq )(d) 
iEint : Egen \ E$m) A iE OU [ = Eg en \ E/;\i\/) 
q' = (q"®E int )®E in 

- (24) 

Where E om : seq Eenv denotes the sequence of generated outgoing event instances and E mt : seq E$m denotes 
the sequence of generated internal event instances. 

□ 

The event instances in E ou , are sent by the state machine to the environment (i.e., to the particular system 
components). The function perm : PseqA —> Pseq(seqZ) takes a set as input and yields the set of possible 
permutations. The function ^ j : seq ( seq X) —> seq X flattens a sequence of sequences (i.e., the particular 
sequences will be concatenated to a single sequence). The function performAll: seq A —r D —> (I), seq E) 
takes a sequence of actions and a data space assignment as input and yields an ordered pair comprising the 
new data space assignment and the sequence of generated events. performAll calculates the intrinsic effect 
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which results from the execution of all transitions in the firing transition set. To illustrate Definition 28 we 
list a sample ML implementation in Section 5. 


Remark: From the literature related to the semantics of Statecharts (e.g., [7, 8]) it is well known that 
write conflicts to data variables can happen due to the parallel execution of transitions. This happens if two 
transition try to write to the same data variable. A lot of conflict resolution strategies have been proposed, 
for example, the so-called interleaving semantics, where conflicts are resolved in non-determinism. Such 
conflicts cannot happen during the execution of transitions in UML state machines. These conflicts are 
avoided by the sequential execution of transitions. 


4 Summary 

The UML state machines semantics is adapted from the STATEMATE semantics [7] to fit into the object- 
oriented paradigm [6], The Statemate semantics itself is related to the classical Harel Statecharts [4, 16, 5], 

We presented an operational semantics which is complete for the considered subset and which includes all 
necessary definitions to implement it. Moreover, it is the first formalization which includes all definitions 
related to the use of complex structured data in state machines. The presented semantics partly benefits 
from previous works (e.g., [i, 18, 15, 2, 13, 14, 11, 12, 21, 3]). A review of several semantics can be 
found in [ 1 9]. Most approaches focus on specialized applications and use specialized notations, or the used 
subset differs from ours. Moreover, there have been major changes in UML 2 that require a deep revision 
of previous works. 


5 Sample ML Implementation 


signature SM_STRUCTURE = 

sig 

type D; (* type of data space *) 

type E; (* type of events *) 

end ; 

signature STATEMACHINE = 
sig 

type D; (* type of data space *) 

type E; (* type of events *) 

(* type of guards: predicate over an event (from transition) and *) 
(* a data space assignment *) 

datatype G = guard of D — > bool ; 

(* type of actions: function that creates an event 
(* data space wrt an event (from transition) and a 
(* assignment 

datatype A = event of D — > E [ update of D — > D; 

(* type of transitions (incomplete) *) 
datatype T = transition of E —> G * A list ; 

(* example step implementation *) 

(* not considering the configuration and the event pool *) 
val partialStep : T —> E * D —> D * E list ; 


or updates a *) 
data space *) 
*) 
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end ; 


functor SM( structure sm_struc : SMJSTRUCTURE) : STATEMACHINE = 
struct 

type D = sm_struc .D; 
type E = sm_struc.E; 

datatype G = guard of D —> bool ; 

datatype A = event of D — > E | update of D —> D; 

datatype T = transition of E —> G * A list ; 

(* perform one single action *) 

(* input: data space assignment and list of (generated) events *) 


(* yields: new data space assignment and new event list *) 

(* perform single action: append a new generated event to the *) 

(* event list or update the data space; function f holds the *) 

(* action *) 

fun perform Action (event(f)) (d,es) = (d, es @ [ f (d ) ]) 
performAction(update(f))(d,es) = (f(d), es) 


(* fold left: function f will be the composition function o and *) 


(* the neutral element will be the id function *) 

(*fold(o,[f, g, h])(n)=ho(go(fon)) *) 

fun fold ( f , n ) ([ ]) = n 

fold ( f , n ) (x : : xs ) = fold (f , f (x , n )) ( xs ); 

(* sequential composition of all actions *) 

(* perform all actions: apply perfomAction to every action and *) 
(* then (sequentially) compose all actions *) 


fun perform All Ac tions ( ac ti o n s )(d) = 

fold(o, fn x => x)(map( perform Action )( ac t ion s ))( d ); 


(* combination of guard checking and performing all actions *) 

(* yields a new data space assignment and a list of all *) 

(* generated events if the guard is satisfied or the old data *) 

(* space assignment and an empty list otherwise *) 


fun p art i al S tep ( tr an s i t ion (t )) ( e , d) = 

1 e t 

val (guard(g), actions) = t(e); 
in 

if g(d) then 

performAllActions ( actions )(d , []) 
else (d, []) 

end ; 

end ; 

Listing 1: Sample Implementation of a Semantical Step 


partialStep(tl)(a(3,true),(3,true)) => ((5,true), [a(4,true),a(8,true),b(false)]) 

4 use ” statemachine . ml ” ; 

6 (* example structure of a state machine *) 

structure sml.struc = 

8 struct 

io (* the data space is constituted of an int value and a boolean *) 
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boolean p2 = true; int pi = 3; 



Figure 5: State Machin for the Listing 2 


(* 

value; 

for example: dataspace (1 1 , true) 



*) 

datatype D 

= dataspace of int * 

bool ; 




(* 

event a 

carries an int and a 

boolean value 

and event 

b 

*) 

(* 

carries 

a boolean value; for 

example : a (5 , 

false ) and 

b( true ) 

*) 


datatype E = a of int * bool | b of bool; 
end ; 

(* instantiate state machine 1 *) 

structure sml = SM( structure sm_struc = sml.struc ); 


(* transition 11 : *) 

(* a(x,y)[x == plj / pl+ + ; a(pl, p2); pl+ + ; a(pl+x, p2); b(not y) *) 
val tl = sml . t r a n s i t i o n ( fn sm 1 _struc . a(x , y) => 

(* guard *) 

(sml.guard(fn sm 1 _struc. dataspace(pi , p2) => x = pi). 


(* effect for (dataspace(pi, p2) and a(x,y)) *) 

[ 

sml . update ( fn sm 1 _strue . dataspace (pi , p2) => 

sm 1 _strue . dataspace (pi +1 , p2)), (* pl++ *) 

sml.event (fn sm 1 _s true.dataspace(pi,p2) => 

sm 1 _strue . a(pi , p2)), (* a(pl, p2) *) 

sml . update ( fn sm 1 _strue . dataspace (pi , p2) => 

sm 1 _strue. dataspace(pi+ 1, p2)), (* pl++ *) 

sml . event (fn sm 1 _struc . dataspace (pi , p2) => 

sm 1 _strue.a(p1 + x, p2)), (* a(pl + x, p2) *) 


sml . event (fn sm 1 _s true . dataspace (pi , p2) => 

sm 1 _struc . b ( not y)) (* b(not y) *) 

] 

)); 


sml . partialStep (tl )( sml.struc .a(3 , true ) , 

sm 1 _struc . dataspace (3 , true)); 


(* partialStep applied to tl , a(3,true) and (3,true) *) 

(h= yields : *) 

(* (dataspace (5, true), [a (4, true), a (8, true), b false]) *) 


Listing 2; Beispiel f374r die Ausf374hmng eines semantischen Schritts 
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